1. Field of the Invention
This invention relates to programming languages and, more particularly, to an abstract language for specifying algorithms for manipulating the hardware state within a system.
2. Description of the Related Art
The hardware elements of a computing machine are generally architected and designed such that certain methods are required to access and manipulate its state in a safe, consistent manner. In most cases, expression of these methods (algorithms) requires not only intimate knowledge of the hardware and the complexities of the interaction between hardware components, but also a detailed understanding of the system specifications.
When software is written to implement all of the hardware manipulation algorithms, programmers frequently do not have the expertise to correctly and efficiently handle the hardware documentation. Thus, software implementation of these manipulation algorithms can be tedious, slow and error-prone.
When working to ensure correct design and operation of the platform, the hardware state transitions and management in many cases is poorly documented, meaning that hardware/system simulation, validation, quality assurance, regression testing, and other activities are left without a single point of reference. For example, system simulation and validation verifies that the hardware operates correctly for all required manipulation algorithms prior to device tape-out. Hardware validation testing of both the entire system and its components are usually done whenever changes are made to the hardware components or the design. The hardware validation tests are typically done far in advance of software engagement, thus the algorithms to manipulate the hardware must be available via other means. Even though the software implementation should match the test algorithms, the hardware test algorithms and the hardware simulations are typically done by different people using their own respective understandings of the hardware design. There is generally no assurance that the hardware architecture and the design meet all the anticipated use cases for it before the software implementation proceeds. In such environments, there is generally no coupling between the algorithms and what software implements during later phases of implementation and thus there is little or no guarantee that the software will necessarily provide the intended result.
Further, when changes occur in the hardware (e.g., system changes, board changes, component changes) there is typically no rigorous means of readily understanding what changes to the hardware manipulation algorithms are required and what testing and regression testing is needed. Thus, currently, even when small changes are made, there may be independent activities in hardware testing, QA testing and software implementation to discover what the impact really is. Thus, there is virtually no way to systematically understand the implications of the changes for all participants.
Typically, the software that is written to manipulate a platform's hardware is derived from a variety of hardware specifications (sometimes of widely variable quality) combined with numerous other platform specifications and hallway conversations. The result must often be iterated upon to get the software right, due to imprecision of definition. Worse still, requiring skilled programmers to understand detailed hardware specifications is a weak link.